home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / mospf / mospf-minutes-92mar.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  3.8 KB  |  108 lines
  1. This is only a rough draft - Megan 04/20/92
  2.  
  3. MOSPF WG meeting, Monday afternoon March 16, 1992
  4.  
  5. Steve Deering - Chair
  6. Keven Rowett  - Notetaker
  7.  
  8. Agenda
  9.  
  10.    IETF audio multicast experiment
  11.    John Moy - implementation experiences of MOSPF
  12.    Inter-domain multicast routing
  13.    internet draft to proposed RFC? 
  14.  
  15.  
  16. Deering described the efforts to provide audio of various
  17. IETF sessions to people unable to attend.
  18.  
  19. The equipment used is a Sun workstation, taking advantage of the
  20. Sparc built-in 79C30 codec.  IP multicasting is being used to relay
  21. audio via IP tunneling around routers which don't support IP 
  22. multicast routing.  Destinations include Hawaii, Australia,
  23. Sweden, and the U.K.
  24.  
  25. Steve noted that the package provides for talk-back from the distant
  26. participants, but locally they have been unable to interconnect with
  27. audio PA system. (Subsequently demonstrated at the Thursday Plenary).
  28.  
  29. John Moy's experiences with implementing MOSPF.
  30.  
  31. Suggested changes as a result of implementing:
  32.  
  33. 1) only one wildcard bit in router-LSA.
  34.  
  35.     0   0   0   0   wildcard  VL  ASBR   ABR
  36.  
  37.     Only one wildcard option was ever really needed.
  38.  
  39. 2) Remove IGMP enable/disable switch:
  40.  
  41.     DL unicast -> IGMP off
  42.     MC fwd off -> IGMP off
  43.     Else IGMP on.
  44.  
  45.     IGMP switch doesn't provide any new information.
  46.  
  47. 3) No more one directional links in OSPF (LSinfinity
  48.    loses meaning in router-LSA).
  49.  
  50.    This is actually a subject of OSPF WG, but wants 
  51.    both groups in synch.
  52.  
  53.    Eliminates disparity between UNICAST and Multicast routing
  54.    tables.
  55.  
  56.    Scott Brim questioned if OSPF can force IGMP off, 
  57.    especially if BGP is also present.
  58.  
  59. Multicast forwarding models
  60.  
  61.    John proposed a mixture of the BSD and MOSPF models (see illustrations
  62.    in accompanying viewgraphs).  The proposed scheme could result in
  63.    duplicate packets to multi-homed hosts.
  64.  
  65.    For packets originated in local machine, a check is required to see if
  66.    local netowrk looped back the packet. i.e. a LAN (or LAN interface) that
  67.    does forward originated packets.  This forces MOSPF forwarding decision
  68.    to check source address does not equal the local address.  TTL value is
  69.    one less after MOSPF hop (seems reasonable).
  70.  
  71. John's plans for document re-organization:
  72.  
  73. 1)  more on initialization of DIJKSTRA SPF algorithm.
  74. 2)  multicast portion of DIJKSTRA algorithm not optional;
  75.     everyone must do identical DIJKSTRA for consistent tie-breaking.
  76. 3)  add an appendix with tie-breaking examples, just to make sure
  77.     everyone gets this part right.
  78.  
  79. MOPSF implementation notes:
  80.  
  81. John noted that the hardest part of his MOSPF implementation was keeping
  82. the unicast and multicast DIJKSTRA algorithm in synch.  Multicast routing
  83. table starts with the unicast table.  If the unicast table is not right,
  84. then multicast won't ever be.  Must tie multicast forwarding cache
  85. maintenance to unicast routing tables changes.
  86.  
  87. John asked if IGMP queries should be done over point-to-point links?
  88. Steve suggest that yes, they should be done on p-to-p links because,
  89. for example, the link might be to a host or to a non-MOSPF router.
  90.  
  91. John also suggested that it might be possible to do multipath multicast
  92. routing by using more creative tie-breaking during tree construction.
  93. The idea is intriguing, but needs more thought.  Could possibly use a
  94. hash of the source address, or the (source, destination) pair, to select
  95. among multiple route choices.
  96.  
  97. John estimated that his implementation took him the equivalent of
  98. 30 full-time working days to complete; it added 20% to the size of the
  99. OSPF code.
  100.  
  101. It was agreed that, after John makes his final pass through the MOSPF draft,
  102. we would submit for publication as an Proposed Standard RFC.
  103.  
  104. The agenda topic on inter-domain multicasting was not addresses, due to
  105. time limitations and lack of enthusiasm.  (We have gone over that
  106. territory at every previous meeting.)
  107.  
  108.